In a dual mode CS/IMS system, speech/video calls can be provided to mobile terminals via either the CS domain or via the IMS, e.g. as a Voice over IP (VoIP) call. In order to avoid having to maintain and update both the legacy CS and the emerging IMS Core Network, many companies are looking to centralise the control of speech/video related services in only the IMS Core Network. However, for example, not all IP Connectivity Access Networks (IP-CANs) can support the Quality of Service (QoS) required by VoIP services, so in order to allow access to centralised services where VoIP capable IP-CANs are not available, the 3rd Generation Partnership Project (3GPP) is defining means by which terminals can use the CS domain to connect to and access services provided by the IMS. This is known as IMS Centralised Service control or “ICS”.
One of the issues that arises in the case of dual mode terminals operating in dual mode networks, is that of domain selection for a speech call. In the case of a Mobile Originating (MO) call, it is relatively straightforward for the user equipment (UE) originating a call, e.g. a cellular phone or the like, to select in which domain to initiate the call if the UE knows the capability of the access network to support VoIP. Further, within the confines of the presently proposed ICS solutions, the UE can determine whether to use the Session Initiation Protocol (SIP) via a PS based signalling channel in parallel with CS bearer establishment or an IMS CS Control Protocol (ICCP) via USSD (or rely on CAMEL triggering) to be able to utilise ICS.
In ICS, the terminal is represented by a remote user agent (RUA) in the IMS so that the terminal appears to be connecting via an IP-CAN for speech/video services even if there is no IP-CAN present, or if the available IP-CAN cannot support speech/video.
The ICS solutions as presently defined considers two possible scenarios:
1. There is no IP-CAN available i.e. there is no PS domain coverage, or it is not possible to transmit and receive via PS in parallel with CS;
2. There is IP-CAN coverage available that can be used in parallel with CS, but the IP-CAN does not support speech or video (e.g. VoIP).
In the case of 1, the present ICS solutions propose that CS calls from the terminal can either:
a. be re-routed using CAMEL triggers to the IMS for centralised service provision; or
b. be established directly towards the IMS CS Control Function (ICCF) in the network with associated SIP session parameters being sent to the ICCF via ICCP over USSD.
In the case of 2, the present ICS solutions propose that a standard SIP INVITE is sent towards the Called Party that is routed via the ICCF due to initial Filter Criteria (iFC) processing at the serving Call Session Control Function (S-CSCF). The terminal then establishes a CS bearer towards the ICCF using standard CS Call Control.
In both cases the ICCF correlates the CS bearer with the information received via USSD or in the SIP INVITE and establishes a session towards the Called Party via the IMS. The originating terminal can then use either SIP signalling, or USSD (depending on the capability of the access network) to control and configure services in IMS for that call.
As discussed above, the terminal makes the decision of how and via which access domain to establish an MO call. A challenge however, exists in the case of Mobile Terminating (MT) calls. The current solutions envisage that a Domain Selection Function in the ICCF (perhaps with the help of the terminating terminal) will determine via which access domain to route a telephone call for mobile termination. This requires that the ICCF is somehow able to know, and be updated with, the capability of the IP-CAN and local access network which the terminating terminal is currently in, in order to determine whether to use USSD or SIP via PS to contact the terminal. It is not entirely clear how the ICCF will be able to know this, but it has been suggested that the terminal could send information about the capability of the local access network to the ICCF to help it make that decision. It has already been proposed (e.g. see UK patent application 0601007.8 whose whole contents in hereby incorporated herein by reference) that the network provides an indication of its VoIP capability to the terminal to aid MO access domain selection. Contributions to SA2 (e.g. NSN paper S2-072459) have proposed that the terminal may signal the VoIP capability of its current access domain to the ICCF to help the network select the terminating domain.
FIG. 1 shows an example of the existing terminating call domain selection functionality for ICS. In this case, the IMS has to know about and be updated with—the VoIP and simultaneous CS/PS capability of the access network in order to determine via which domain to attempt termination of the call and how to signal the incoming call to the terminal. This would incur significantly extra signalling overhead between the network and the terminal as the information would have to be updated as the terminal moves within the network.
As shown in FIG. 1, following arrival, at S1, of a call notification, the ICCF checks, at S3, if the terminating terminal is IMS registered. If the terminating terminal is IMS registered, the ICCF checks, at S5, if the terminating terminal is currently in an access network which supports VoIP, and if so sends, at S7, an SIP INVITE to the terminating terminal via the PS domain indicating that a VoIP call is to be established. On receiving the SIP INVITE, the terminating terminal then responds, at S9, using a SIP 18x message and a normal IMS session ensues.
If the terminating terminal is IMS registered but is currently in an access network which does not support VoIP, the ICCF checks, at S11, if the terminating terminal is currently in an access network which supports simultaneous PS and CS communication. If so, the ICCF sends, at S13, an SIP INVITE to the terminating terminal via the PS domain indicating that a call is to be established utilising a CS bearer for media and a PS control channel. Following receipt of the SIP INVITE, the terminating terminal responds, at S15, using SIP via the PS domain and establishes a CS bearer towards the ICCF for transport of media. The IMS session then ensues, at S17, using CS bearer for media and SIP via PS domain for control and configuration of services.
If the terminating terminal is not IMS registered, or if the terminating terminal is IMS registered but is not able to receive PS and CS in parallel, then the ICCF checks, at S19, if the terminal is registered to receive IMS via the CS domain. If so, the ICCF sends, at S21, an incoming call notification to the terminating terminal via USSD. On receipt of the incoming call notification, the terminating terminal responds, at S23, using USSD via the CS domain and establishes a CS bearer towards the ICCF for transport of media. The IMS session then ensues, at S25, using CS bearer for media with ICCP via USSD for control and configuration of services.
If the terminal is not registered to receive IMS services, the ICCF checks, at S27, if the terminal is registered to receive normal CS. If so, the ICCF completes, at S29, the session as a standard CS call towards the terminal. If not, the ICCF determines, at S31, that the call cannot be completed.